AWS Transit GatewayでVPC間を接続しているとセキュリティグループIDで通信を制御できない事象に遭遇した

VPCピアリングからAWS Transit Gatewayに切り替えたら通信できなくなったのだが

こんにちは、自称Transit Gatewayおじさんの のんピ(@non____97)です。

皆さんはTransit Gateway好きですか? 私は好きです。

以前の記事でVPCピアリングからAWS Transit Gatewayに切り替える方法を紹介しました。

今回、VPCピアリングからAWS Transit Gatewayに切り替えた際に、Transit Gatewayで接続したVPC上のEC2インスタンス間で通信できなくなる事象に遭遇しました。

原因はタイトルにある通り、「セキュリティグループのインバウンドルールでセキュリティグループIDを使って通信を制御していた」ためでした。具体的にどういった構成を取った時にこの事象が発生したのか紹介します。

いきなりまとめ

• VPCピアリングでVPC間を接続している場合はセキュリティグループIDで通信を制御できる
• AWS Transit GatewayでVPC間を接続している構成で、対向VPCのセキュリティグループIDを指定している場合に通信できない

検証してみた

VPCピアリングでVPC間を接続している場合

まず、VPCピアリングでVPC間を接続している構成で、セキュリティグループIDを用いて通信を制御できるか確認してみます。

構成は以下の通りです。各VPC上のEC2インスタンスにアタッチしているセキュリティグループのインバウンドルールで、対向のEC2インスタンスにアタッチしているセキュリティグループIDからのICMPを許可した状態で、互いにpingを実行します。

VPC AのEC2インスタンスのセキュリティグループのインバウンドルール

VPC BのEC2インスタンスのセキュリティグループのインバウンドルール

それぞれのpingの実行結果は以下の通りです。正常に全てのICMPパケットが到達できることが確認できました。

# 自分のIPアドレス確認
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0e:05:15:2c:4b:ef brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.183/24 brd 10.0.0.255 scope global dynamic eth0
       valid_lft 2030sec preferred_lft 2030sec
    inet6 fe80::c05:15ff:fe2c:4bef/64 scope link
       valid_lft forever preferred_lft forever

# VPC AのEC2インスタンスからVPC BのEC2インスタンスへping
$ ping 10.0.1.245 -c 4
PING 10.0.1.245 (10.0.1.245) 56(84) bytes of data.
64 bytes from 10.0.1.245: icmp_seq=1 ttl=64 time=0.825 ms
64 bytes from 10.0.1.245: icmp_seq=2 ttl=64 time=0.887 ms
64 bytes from 10.0.1.245: icmp_seq=3 ttl=64 time=0.846 ms
64 bytes from 10.0.1.245: icmp_seq=4 ttl=64 time=0.858 ms

--- 10.0.1.245 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3068ms
rtt min/avg/max/mdev = 0.825/0.854/0.887/0.022 ms

# 自分のIPアドレス確認
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0a:4b:30:d9:62:73 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.245/24 brd 10.0.1.255 scope global dynamic eth0
       valid_lft 3272sec preferred_lft 3272sec
    inet6 fe80::84b:30ff:fed9:6273/64 scope link
       valid_lft forever preferred_lft forever

# VPC BのEC2インスタンスからVPC AのEC2インスタンスへping
$ ping 10.0.0.183 -c 4
PING 10.0.0.183 (10.0.0.183) 56(84) bytes of data.
64 bytes from 10.0.0.183: icmp_seq=1 ttl=64 time=0.891 ms
64 bytes from 10.0.0.183: icmp_seq=2 ttl=64 time=0.840 ms
64 bytes from 10.0.0.183: icmp_seq=3 ttl=64 time=0.855 ms
64 bytes from 10.0.0.183: icmp_seq=4 ttl=64 time=0.864 ms

--- 10.0.0.183 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3017ms
rtt min/avg/max/mdev = 0.840/0.862/0.891/0.034 ms

片方のVPCをVPCピアリング、もう一方のVPCをTransit Gatewayで接続している場合

次に、片方のVPCをVPCピアリング、もう一方のVPCをTransit Gatewayで接続している構成で、セキュリティグループIDを用いて通信を制御できるか確認してみます。

構成は以下の通りです。先の検証と同じように各VPC上のEC2インスタンスにアタッチしているセキュリティグループのインバウンドルールで、対向のEC2インスタンスにアタッチしているセキュリティグループIDからのICMPを許可した状態で、互いにpingを実行します。

それぞれのpingの実行結果は以下の通りです。Transit Gatewayを通る「VPC A -> VPC B」の経路でICMPパケットが到達できなくなりました。どうやら通信がTransit Gatewayを通る構成で、対向VPCのセキュリティグループIDを指定している場合に通信できないようですね。

# VPC AのEC2インスタンスからVPC BのEC2インスタンスへping
$ ping 10.0.1.245 -c 4
PING 10.0.1.245 (10.0.1.245) 56(84) bytes of data.

--- 10.0.1.245 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3075ms

# VPC BのEC2インスタンスからVPC AのEC2インスタンスへping
$ ping 10.0.0.183 -c 4
PING 10.0.0.183 (10.0.0.183) 56(84) bytes of data.
64 bytes from 10.0.0.183: icmp_seq=1 ttl=63 time=1.41 ms
64 bytes from 10.0.0.183: icmp_seq=2 ttl=63 time=1.01 ms
64 bytes from 10.0.0.183: icmp_seq=3 ttl=63 time=1.25 ms
64 bytes from 10.0.0.183: icmp_seq=4 ttl=63 time=0.988 ms

--- 10.0.0.183 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.988/1.168/1.416/0.177 ms

Transit GatewayでVPC間を接続している場合

最後にTransit GatewayでVPC間を接続している構成で、セキュリティグループIDを用いて通信を制御できるか確認してみます。

構成は以下の通りです。同様に各VPC上のEC2インスタンスにアタッチしているセキュリティグループのインバウンドルールで、対向のEC2インスタンスにアタッチしているセキュリティグループIDからのICMPを許可した状態で、互いにpingを実行します。

それぞれのpingの実行結果は以下の通りです。やはり「VPC A -> VPC B」の経路に加えて「VPC B -> VPC A」の経路でも通信できなくなりました。

# VPC AのEC2インスタンスからVPC BのEC2インスタンスへping
$ ping 10.0.1.245 -c 4
PING 10.0.1.245 (10.0.1.245) 56(84) bytes of data.

--- 10.0.1.245 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3067ms

# VPC BのEC2インスタンスからVPC AのEC2インスタンスへping
$ ping 10.0.0.183 -c 4
PING 10.0.0.183 (10.0.0.183) 56(84) bytes of data.

--- 10.0.0.183 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3064ms

以上の検証からTransit Gatewayを使用した構成では、互いのVPC上のセキュリティグループIDを使って通信を制御するように設計してはならないと判断できます。

VPCピアリングからAWS Transit Gatewayに切り替える場合はセキュリティグループのルールをチェックしよう

AWS Transit GatewayでVPC間を接続しているとセキュリティグループIDで通信を制御できない事象を紹介しました。

VPCピアリングからAWS Transit Gatewayを使った構成に変更する場合は、セキュリティグループのルールでTransit Gatewayを介して接続しているVPC上のセキュリティグループIDを使っていないかどうかを確認する必要があります。もし使用している場合は、セキュリティグループIDではなく、CIDRブロックやプレフィックスリストを使って制御する必要があります。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!